1. Field of the Invention
The present invention relates to the field of computer networking. More particularly, the present invention relates to a method and an interface for storing identification information on network devices.
2. The Background Art
A computer network contains a number of hardware devices connected to each other via the network. Each hardware device normally contains information on the identification of that device. This information is usually stored on a programmable read only memory chip (PROM) but any number of non-volatile memory storage media are possible. When the memory device is a PROM, it is usually referred to as the ID PROM of the device, even though it is not necessary that the storage medium be a PROM. The type of information stored on each of these devices usually includes identification information such as the device's serial number or its part number.
Device identification information is used by network devices in a number of different fashions. The device actually storing the information may require the information during its use. For example, a device such as a router may use identification information contained within its memory store in order to determine how to control the network. Also, a management station or other device elsewhere on the network may use identification information from the memory store of a device to aid in the management of the system or for a number of other reasons.
FIG. 1 depicts an example of a network in which the management station requests identification information on a device. The management station 10 requests a piece of identification information (e.g. a serial number) from device A 12. This request will travel across the network to the device A 12. An interface 14 built into the device A 12 will then handle the instruction, retrieving the appropriate information from the memory store of the device, and sending the information to the management station 10. The interface need not be contained on the device itself, as it is possible for the management station 10 control all of the information retrieval for each node on the network. However, due to the complexity of most systems, it is often more efficient to have the interface located on each device and designed in such a way that it is streamlined for use with that device.
Storage of the identification information in the memory store of the device is usually performed by the interface as well. FIG. 2 depicts the device A 12 of FIG. 1 in greater detail. The interface 14 receives the information, then stores it in the address or addresses in the memory store 16 that it has assigned to identification information of that type. An example of how an interface may organize identification information is given in table 1. In this example, all of the types of identification information the interface may store are assigned unique register and block addresses in the memory store. "EEPROM version" has been assigned to address 00, while "controller type" has been assigned to address 01, and so on. This is known as a fixed address format, as each type of information is assigned a fixed and unique address or addresses.
There are several disadvantages, however, to using such a fixed address format. As new versions of software and hardware devices are created, there are often additional types of identification information that the manufacturer wishes to place on the memory store of the hardware device. These new fields may not always be foreseen at the time the interface was created. While it is possible to use one of the unused addresses (in the example in Table 1 below there are several unused addresses, including 1A to 1E and 26 to 80), this is a dangerous solution as it is possible that other components of the network may be using those addresses for storage of other types of information. Additionally, this solution requires that the interface be updated to recognize the new information type and to possess the knowledge as to what address the new information type is to be stored.
TABLE 1 Block Address Description 00 EEPROM Version 01 Controller Type 02 Hardware Version High Byte 03 Hardware Version Low Byte 04:07 Serial Number 08 PCA Item Number - Class Code 09:0A PCA Item Number - Base Number 0B PCT Item Number - Version 0C Test History - RMA Failure Code 0D RMA number - Byte 2 0E RMA number - Byte 1 0F RMA number - Byte 0 10 Board Revision 11 Deviation number - (see note 1) 12 Deviation number - (see note 1) 13 Board Configuration 14 Manufacturing Date Code - YY 15 Manufacturing Date Code - MM 16 Manufacturing Date Code - DD 17 Card Connector Type 18:19 ASIC Revision 1A;1E Undefined - Program to FF 1F Development Engineering 20:25 Field Diagnostics 26:30 Undefined - Program to FF
Another drawback of the fixed address format is the fact that it creates the possibility of wasted space on the memory store. All recognized information types must be assigned a unique address or addresses. These addresses must be reserved for the identification information and cannot be used to store other types of information. While it is normally the case that all of the identification information address will be used, there are sometimes situations where some of the addresses may not be used, for example, if a device no longer needs to keep track of a certain information type due to changes in the network setup. It would be preferable to have a system that would not use up any more space than is needed, allowing for the extra space to be used for other functions.
Finally, the fixed address format requires an overly rigid organizational scheme for identification information. The interface must not only keep track of identification information types, but also keep track of the specific addresses where those identification information types are located. The result is an overly complex interface. It would be preferable to have a system that did not require such an overly rigid organizational scheme, and thus would allow for a much simpler interface design.